Skip to content

Conversation

@arvidn
Copy link
Contributor

@arvidn arvidn commented Nov 3, 2025

Purpose:

With hard fork 2, we want to disallow block references. We have not seen any benefit or use of them so far. We currently compress block generators using (internal) back references. Deduplicating structures.

Disallowing block generators has the following upsides:

  • It's much simpler to validate a block, without needing access to the whole chain
  • A node don't necessarily need to keep every block around to validate and be a part of the chain
  • It's cheaper to validate blocks, without requiring additional DB lookups for previous blocks

There are two additional commits in this PR.

  1. Disable simulations of har fork 2 activation, since the existing chains do contain block references, we can't use them in tests after the hard fork. These will be re-enabled once we have new test block chains specifically made with the new consensus rules
  2. fix a flaky (and awkward) test related to rate limits

@arvidn arvidn added the Changed Required label for PR that categorizes merge commit message as "Changed" for changelog label Nov 3, 2025
@arvidn arvidn force-pushed the hard-fork-generator-refs branch from 82dab9f to e90d3c4 Compare November 4, 2025 12:27
@arvidn arvidn force-pushed the hard-fork-generator-refs branch from e90d3c4 to f4a0b5e Compare November 4, 2025 12:54
@arvidn arvidn marked this pull request as ready for review November 4, 2025 13:24
@arvidn arvidn requested a review from a team as a code owner November 4, 2025 13:24
@github-actions
Copy link
Contributor

github-actions bot commented Nov 4, 2025

File Coverage Missing Lines
chia/consensus/block_body_validation.py 66.7% lines 350
chia/consensus/blockchain.py 83.3% lines 710
chia/simulator/block_tools.py 33.3% lines 389-390
Total Missing Coverage
18 lines 4 lines 77%

# 8c. The generator ref list must not point to a height >= this block's height
if block.transactions_generator_ref_list in (None, []):
if block.transactions_generator_ref_list == []:
if block.transactions_info.generator_refs_root != bytes([1] * 32):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is such a bizarre magic number. I'm very puzzled why we wouldn't just use the serialization for the empty list. But I don't suppose it much matters now.

Copy link
Contributor Author

@arvidn arvidn Nov 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this isn't a list, it's a bytes32. it must always be 32 bytes in the serialization. Still, It could be a named constant.

# 8b. The generator ref list length must be less than or equal to MAX_GENERATOR_REF_LIST_SIZE entries
# 8c. The generator ref list must not point to a height >= this block's height
if block.transactions_generator_ref_list in (None, []):
if block.transactions_generator_ref_list == []:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this just a tidy-up, or is it required?

Copy link
Contributor Author

@arvidn arvidn Nov 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct, this is unrelated. I was a bit surprised mypy didn't flag this. transaction_generator_ref_list is not Optional[]. It can't be None.


# With hard fork 2 we ban transactions_generator_ref_list.
if prev_tx_height >= self.constants.HARD_FORK2_HEIGHT and block.transactions_generator_ref_list != []:
return None, Err.TOO_MANY_GENERATOR_REFS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit puzzled as to why this is checked in multiple places. Maybe one is for all blocks and another is just for "transaction blocks"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We check it in BlockTools, to make sure no test is trying to create an invalid block.
We check it in block body validation, which is the main block validation function.
We also check it when validating unfinished blocks, which is a bit trickier because the height of the block isn't as well known.

Copy link
Contributor

@richardkiss richardkiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a good understanding of this consensus code, but there's nothing in this PR that seems terribly wrong. I guess we just need some tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Changed Required label for PR that categorizes merge commit message as "Changed" for changelog

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants